ASP.NET applications
always work in conjunction with a web server—a specialized piece of
software that accepts requests over Hypertext Transport Protocol (HTTP)
and serves content. When you're running your web application in Visual
Studio, you use the test web server that's built in. When you deploy
your website to a broader audience, you need a real web server, such as
IIS.
Web servers run special
software to support mail exchange, FTP and HTTP access, and everything
else clients need in order to access web content. Before you can go any
further, you need to understand a little more about how web servers
work.
1. How Web Servers Work
The easiest job a web
server has is to provide ordinary HTML pages. When you request such a
file, the web server simply reads it off the hard drive (or retrieves
it from an in-memory cache) and sends the complete document to the
browser, which displays it. In this case, the web server is just a
glorified file server that waits for network requests and dishes out
the corresponding documents.
When you use a web server
in conjunction with dynamic content such as an ASP.NET page, something
more interesting takes place. On its own, the web server has no idea
how to process ASP.NET tags or run VB code. However, it's able to
enlist the help of the ASP.NET engine to perform all the heavy lifting.
Figure 1
diagrams how this process works for ASP and ASP.NET pages. For example,
when you request the page Default.aspx, the web server sends the
request over to the ASP.NET engine (which starts automatically if
needed). The ASP.NET engine loads the requested page, runs the code it
contains, and then creates the final HTML document, which it passes
back to IIS. IIS then sends the HTML document to the client.
At this point, you might
be wondering how the web server knows when it needs to get the ASP or
ASP.NET engine involved. Essentially, the web server looks at the file
extension of the requested page (such as .asp or .aspx) to determine
the type of content. The web server compares this extension against a
list to determine what program owns this file type. For example, the
web server's list indicates that the .aspx extension is owned by the
aspnet_isapi.dll component in a folder like
c:\Windows\Microsoft.NET\Framework64\v4.0.30319 directory (assuming
you're using version 4.0.3319 of .NET on a 64-bit system).
All web servers perform the same task as that shown in Figure 1.
However, when you run an ASP.NET application in Visual Studio, you
don't need to worry about deployment and file type registration. That's
because Visual Studio includes a built-in web server. It receives the
requests for the pages in your web application and then runs the
corresponding code. This test web server has a significant
limitation—it only accepts requests from the local computer. In other
words, there's no way for other people on other computers to access
your website.
To run your web
application outside the development environment, you need a more
powerful web server. The web server software runs continuously on your
computer (or, more likely, a dedicated server). This means it's ready
to handle HTTP requests at any time and provide your pages to clients
who connect from the same network or over the Internet. On Microsoft
Windows operating systems, the web server you'll use is IIS.
In most cases, you won't
be developing on the same computer you use to host your website. If you
do, you will hamper the performance of your web server by tying it up
with development work. You will also frustrate clients if a buggy test
application crashes the computer and leaves the website unavailable or
if you accidentally overwrite the deployed web application with a work
in progress. Generally, you'll perfect your web application on another
computer and then copy all the files to the web server.
In this chapter, you'll learn
how to do all the deployment work—including installing IIS and
configuring your website—by hand. If you're responsible for setting up
the web server (for example, your company has a web server on site, or
you're using your web application to serve a smaller audience on a
local network), you'll need these skills.
However, many developers
aren't so intimately involved in the deployment of their web
applications. Instead, they use a web hosting company that supports
ASP.NET 4. If you're in this situation, you simply need to copy your
web application files to the web server using an FTP program, or the
support that's built into Visual Studio, which you'll explore in the
final part of this chapter. In this case, you may not be as interested
in the specifics of IIS. However, you may still want to review them
just to understand more about how web hosting and IIS work.
|
2. The Virtual Directory
When you deploy your web application to a web server, it's exposed through something called a virtual directory. A virtual directory is simply the public face of your website directory.
For example, your website
might exist in a directory on the server named c:\MySite. To allow
remote users to access this website through their browsers, you could
expose it as a virtual directory. The virtual directory name might
match the real directory name (in this case, MySite), or it might be
something different. When the user requests a page in a virtual
directory (say, http://WebServer/MySite/Checkout.aspx), the web server
looks for the corresponding file in the corresponding physical
directory (c:\MySite\Checkout.aspx). You'll learn more about this
process—how URL requests are processed by the web server—in the next
section.
3. Web Application URLs
You can use ASP.NET applications
in a variety of different environments, including local area networks
(LANs) and over the Internet. To understand the difference, it helps to
review a little about how web servers work with networks and the
Internet.
A network
is defined simply as a group of devices connected by communication
links. A traditional LAN connects devices over a limited area, such as
within a company site or an individual's house. Multiple LANs are
connected into a wide area network (WAN) using a variety of
technologies. In fact, the Internet is nothing more than a high-speed
backbone that joins millions of LANs.
The cornerstone of the Internet is Internet Protocol (IP). On an IP network, each computer is given a unique number called an IP address.
An IP address is typically written as four numbers from 0 to 255
separated by periods (as in 192.145.0.1) or as six hexadecimal values
separated by colons (as in 2001:db8:85a3::8a2e:370:7334). The
difference depends on the version of the IP standard that you're
using—the older, more common IPv4 standard uses the first approach,
while the newer IPv6 uses the second. Either way, to access another
computer over a network, you need to use its IP address.
Of course, IP addresses aren't
easy to remember and don't make for great marketing campaigns. To make
life easier, web servers on the Internet usually register unique domain names such as www.microsoft.com.
This domain name is mapped to the IP address by a special catalog,
which is maintained by a network of servers on the Internet. This
network, called the Domain Name Service (DNS), is a core part of the
infrastructure of the Internet. When you type http://www.microsoft.com in a web browser, the browser contacts a DNS server, looks up the IP address that's mapped to www.microsoft.com, and contacts it.
So, what effect does
all this have on the accessibility of your website? To be easily
reached over the Internet, the web server you use needs to be in the
DNS registry. To get in the DNS registry, you must have a fixed IP
address. Commercial Internet service providers won't give you a fixed
IP address unless you're willing to pay a sizable fee. In fact, most
will place you behind a firewall or some type of network address
translation (NAT), which will hide your computer's IP address. The same
is true in most company networks, which are shielded from the outside
world.
ASP.NET applications don't need
to be accessible over the Internet. Many are useful within an internal
network. In this case, you don't need to worry about registered domain
names. Other computers can access your website using either the IP
address of your machine or, more likely, the network computer name.
For example, imagine you
deploy an application to a virtual directory named MyWebApp. On the web
server, you can access it like this:
http://localhost/MyWebApp
Remember, localhost is a special part of the URL called a loopback alias.
It always points to the current computer, whatever its name is.
Technically, the loopback alias is mapped to something called the loopback address, which is the IP address 127.0.0.1. You can use the alias or the numeric address interchangeably.
|
|
Assuming the computer is
named MyWebServer, here's how you can access the virtual web directory
on another computer on the same LAN:
http://MyWebServer/MyWebApp
If you don't know the name of
your computer, right-click the Computer icon either on your desktop or
in Windows Explorer, and select Properties. This shows a system
information page that includes your current computer name.
|
|
Now, assume that MyWebServer is registered in the DNS as www.MyDomain.com and is exposed to the Internet. You could then use the following URL:
http://www.MyDomain.com/MyWebApp
Finally, you can always
use the computer's IP address, provided the computer is on the same
network or visible on the Internet. Assuming the IP address is
123.5.123.4, here's the URL you would use:
http://123.5.123.4/MyWebApp
Because internal networks
often use dynamic IP addresses and because DNS registration changes,
using the computer name or domain name to access a website is almost
always the best approach.
If you study the URLs that
the built-in web server in Visual Studio uses, you'll notice they're a
little different than what you usually see when surfing the Internet.
Namely, they include a port number. That means instead of requesting a
page like this:
http://localhost/MyWebApp/Default.aspx
you might request a page like this:
http://localhost:2040/MyWebApp/Default.aspx
That's because the Visual
Studio web server watches requests on a dynamically chosen port number.
(In this example, the port number is 2040, but you'll see that it
changes each time you run Visual Studio.) By using a dynamic port
number, Visual Studio makes sure its built-in web server doesn't
infringe on any other web server software you have on the computer.
Real web servers are almost
always configured to monitor port 80 (and port 443 for encrypted
traffic). If you don't type in a port number for a URL, the browser
assumes you're using port 80 for ordinary web access and port 443 for
secure connections.
4. Web Farms
Some applications run on web farms,
a group of server computers that share the responsibility of handling
requests. Usually web farms are reserved for high-powered web
applications that need to be able to handle heavy loads, because
multiple computers can deal with more simultaneous surfers than a
single web server. However, web farms are overkill for many small and
midsized websites.
The way a web farm works is
deceptively simple. Essentially, instead of placing web application
files on a single web server, you place a copy on several separate web
servers. When a request is received for your website, it's directed to
one of these web servers (based on which one has the lightest load).
That web server then deals with the request. Obviously, if you decide
to update your application, you need to make sure you update each web
server in the web farm with the same version to prevent discrepancies.
Some web hosting companies use
web farms to host multiple websites. For example, your website might be
running on more than one web server, but each of these web servers
might also host multiple websites. This provides a flexible deployment
model that lets different web applications share resources. However,
web farms also introduce a few new challenges. If you're setting up a
web farm of your own, you'll need to make sure each computer uses the
same machine key.